Carnegie Mellon's Software Development Studio: A Five Year Retrospectiv

The Software Development Studio is the centerpiece of Carnegie Mellon's Master of Software Engineering Curriculum. It represents 40 per cent of the course units students spend in the program. The Studio has continuously evolved since its prototype in the spring and summer of 1990. The lessons learned about organization, projects, and other issues are the subject of this paper. The use of a well-established development process, a matrix organization, and one-on-one mentoring give the highest return on investment. This is being written as the seventh class of students prepare to enter the Carnegie Mellon University (CMU) Master of Software Engineering (MSE) Program. The program is a joint effort of the School of Computer Science and the Software Engineering Institute at CMU. The curriculum for the MSE has continuously evolved since its inception, though there have been no major changes for two years. The concept-based core curriculum, representing 30 per cent of the units required for the degree, is documented in [2]. The prototype offering of the Studio course, 40 per cent of the units students take, is described in [10]. This paper presents the lessons learned in the five 16-month Studio offerings since then. Twelve projects, some of which were continuations of previous projects, staffed by just under 70 students, form the database from which the following information is drawn. Philosophy and project selection The underlying pedagogical philosophy of the Studio is unchanged since its inception. The MSE is a terminal professional degree program, much like an MBA or five-year architecture curriculum. Therefore, the Studio tries to incorporate the best methods of educating professionals, such as those described in the books of Donald Schön [6, 7]. The essential principle is that of reflective practice. Students are encouraged to do the work while being self-aware of the decisions they make and actions they take. The Studio instructor’s role is more of a mentor, or, better, a coach. Coaches basically maintain a vision of best practice, observe the student’s efforts to match that vision, and give advice to help them in later attempts. A Studio mentor thus most frequently asks why questions, and makes did you consider suggestions. The most important thing is that the coach can not do the work for the student, just as an architecture professor does not do the design of a student project. Rather, they react to the student’s work in order to help the student see what is successful and how a wrong road taken can be avoided in the future. Another thing that has not changed about the Studio since 1989 is the set of criteria used selecting Studio projects. These criteria include the requirements that the project be of some intended use, be embedded in a larger effort, and provide opportunities for individual students to excel. The desire is to combine aspects of programming in the many with the application of material learned in the core courses. One of the best projects that illustrates the fulfillment of these criteria is development of the Tessellator. The Tessellator is a robot built to automate the maintenance of the Space Shuttle thermal protective system. Each of the thousands of individual tiles on a Shuttle orbiter must be waterproofed by injecting a chemical into them. They must also be inspected for damage. These two tasks are perfect for a robot: they are repetitive and tedious. Two Studio teams in consecutive classes built the movement and positioning software, the arm control software, and the database and work planning software for this robot. The Studio project was embedded in a team consisting of Rockwell, SRI, Boeing, and CMU’s Field Robotics Center. Fourteen MSE students worked on the robot as well as several dozen others from the other partners. The story of this project would be a paper in itself, but it suffices here to say that the MSE students set a standard of engineering the other teams scrambled to emulate. The most effective way to create an atmosphere of reality while still avoiding anyone’s critical path are choosing projects that are proof of concept (such as the Tessellator), or risk reduction prototypes. The Studio gives a client an opportunity to try out new things with some of the best available software engineering formalisms and processes. It has been no trouble finding suitable clients, but there has been some trouble helping them remember that the Studio is not a consulting firm with profit-making aspirations. This will be explored further in a later section. First, we will overview a typical scenario in the Studio as it is now constituted.